1. Field of the Invention
The present invention relates generally to the field of diagnostic tools for computer software. More specifically, the present invention relates to real-time upgrade or other modification of a computer application without terminating or suspending the application's execution.
2. Background of the Invention
Web-based software applications often execute on application server platforms. Examples of application server platforms include systems such as iPlanet or Weblogic. Due to their nature, it is desirable to keep web-based applications, highly available. Thus, minimizing their downtime is a critical goal. However, this goal can pose significant problems in the trouble-shooting and maintenance environment of most information technology (IT) facilities. Downtime is often required to debug software problems or to upgrade systems. Downtime is also required to maintain systems or find and repair errors. This downtime can have enormous impacts on IT facilities' operations and viability.
Conventional software maintenance tools do not adequately solve the problem of modifying or upgrading an application during its normal unimpeded execution. There are several ways of upgrading or modifying applications in conventional systems. In one technique, upgrades or modifications are performed only at scheduled maintenance times. At the scheduled maintenance time, systems personnel are provided a window of time in which any maintenance operations should be performed. Systems personnel make any required changes, and restart the application within the maintenance window. One problem with the scheduled-maintenance-window approach is that maintenance windows may be scheduled only once or twice a day or even less often. Consequently, there is often a significant delay between the time maintenance is required to resolve non-routine problems, and when the systems personnel are actually allowed to perform it.
Another problem with the scheduled-maintenance-window approach is that a system operator must be available at the scheduled maintenance time. Due to the dynamic nature of IT facilities, system operators might be assigned to other tasks at the scheduled maintenance time. If a system operator is not available to perform an upgrade during the allotted time, the upgrade must wait until the next scheduled maintenance time. Unfortunately, the next scheduled maintenance time could be hours or days away. Moreover, there is no guarantee that a system operator will be available to complete the required maintenance, because even a simple upgrade may take a significant amount of time to install.
A second maintenance technique is a reactive strategy—system maintenance or upgrades are performed only when catastrophic failures have occurred or are imminent. Consequently, the second option is used primarily in emergency situations, such as when a system component fails. When the emergency occurs, the application is terminated so that it can be diagnosed or repaired. After the appropriate maintenance or upgrade is completed, the application is restarted using the updated instructions or data.
The delay between diagnosis and repair of a problem can be significant. Due to the high premium most web-based applications place on availability, this is an unacceptable solution. Another problem with suspending or terminating an application is that any transaction currently in progress is interrupted, and often lost, when the application is terminated.
Another conventional technique to handle error conditions is to account for possible errors in the application software in the form of contingency software to handle error conditions. Contingency software enables an application to react to an error in a graceful or predictable manner. The contingency software is embedded in the application. Consequently, the contingency software is compiled as a part of the application and becomes part of the application's executable code.
One drawback of using the contingency software is that it becomes a fixed part of an application's executable code. Consequently, it is not dynamic. Thus, if an unexpected contingency occurs, there is no software in the program to accommodate it. For this reason, contingency software embedded an application is an incomplete solution.
Consequently, there is a need for a computer software diagnostic tool that allows system operators to maintain or upgrade a computer application without terminating or suspending the application's operation or adding to the size of executable code.